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Section  2 


BACKGROUND 


The  Organization  for  Industrial  Research  is  a  company  committed  to 
the  philosophy  of  Group  Technology.  However,  OIR  believes  in 
realistic  and  practical  applications  of  Group  Technology  within 
manufacturing  environments  and  has  over  fifty  American  customers 
and  seventy  installations  of  its  systems  as  confirmation  of  its 
philosophy  and  approach. 

OIR  strongly  believes  in  an  integrated  approach  to  CAD  and  CAM 
systems.  Over  ten  years  of  practical,  on-site  experience  has 
unequivocally  demonstrated  the  benefits  of  an  integrated  systems 
approach  rather  than  numerous  systems  in  isolation.  Group 
Technology  can  become  "glue"  technology  and  be  the  essential 
ingredient  in  achieving  integration  of  CAD  and  CAM  systems.  OIR 
has  shown  that  a  Group  Technology  classification  and  coding  system 
can  become  the  common  denominator  among  different  CAD/CAM  systems 
and  applications.  The  MICLASS  code  is  at  the  core  of  all  OIR 
systems . 

An  important  part  of  the  many  Group  Technology  system 
implementations  OIR  performs,  is  code  design  and  development. 

Each  application  of  an  OIR  system  requires  the  development  of  a 
specific  code  for  a  particular  environment,  in  addition  to  OIR's 
standard  Group  Technology  Classification  and  Coding  System.  This 
specific  code  is  an  extension  of  the  standard  code.  In  this  way, 
each  company  can  make  best  use  of  proven,  industry  wide  data 
captured  in  the  standard  section  of  the  code,  yet  still  have  a 
section  of  the  code  specific  to  its  own  needs  and  requirements. 

Additionally,  OIR  has  developed  other  types  of  Group  Technology 
Classification  and  Coding  Systems  for  different  applications 
(i.e.  Purchased  Parts  Coding  System).  These  coding  systems  have 
been  in  direct  response  to  client  requests. 

Code  development  can  be  an  extremely  time  consuming  task 
requiring  a  highly  labor  intensive  effort.  OIR  has  significantly 
reduced  the  time  and  manpower  requirements  for  this  task  by  using: 

•  inhouse  expertise  gained  through  years  of  experience; 

•  computerized  Group  Technology  analysis  programs. 

Contract  No.  DAAK10-80-C-0189  required  OIR  to  define  the 
fundamentals  of  a  Group  Technology  Electronics  Classification  and 
Coding  System.  This  Requirements  Definition  document  will 
identify  the  primary  and  secondary  characteristics  for  an  ECACS. 
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OIR  developed  this  report  based  on  survey  and  interview  data, 
consultation  with  a  panel  of  electronics  experts  and  its  own 
extensive  experience  with  Group  Technology  code  development. 


Section  1 
INTRODUCTION 


Contract  NO.  DAAK10-80-C-0189  was  awarded  by  the  Tri-Service 
Manufacturing  Technology  Program  through  the  Department  of  the 
Army,  U.S.  Army  Armament  R  &  D  Command,  Dover,  New  Jersey  to  the 
Organization  for  Industrial  Research,  Inc.  (OIR).  The  goal  of 
this  contract  was  to  develop  the  fundamentals  of  a  Group 
Technology  Electronics  Classification  and  Coding  System  (ECACS) 
including  a  Requirements  Definition.  This  report  is  the 
Requirements  Definition  document  and  is  the  second  section  of  the 
contract  final  report. 

The  information  found  in  this  report  is  based  on  data  collected  by 
OIR  by  surveying  manufacturers  within  the  electronics  industry. 
Information  regarding  the  survey  process,  survey  findings, 
survey  data  analysis  and  conclusions  can  be  found  in  Report 
DAAK10-80-C-0189,  "Fundamentals  of  a  Group  Technology 
Classification  and  Coding  System:  Summary  of  Survey  Findings". 


Section  3 


ECACS:  GENERAL  CONSIDERATIONS 


OIR  has  developed  a  methodology  for  the  development  of  Group 
Technology  Coding  Systems  based  upon  our  years  of  experience  with 
this  activity.  There  are  certain  general  considerations  which 
must  be  reviewed  before  actual  code  development  is  begun.  In 
order  to  develop  a  classification  and  coding  system  for 
electronics  the  following  must  be  considered: 

•  applications. 

•  existing  software  utility  programs. 

•  code  format  and  layout. 

C 

3 . 1  Applications 


r. 


r 

I.  ■ 


The  development  of  a  classification  and  coding  system  cannot 
begin  until  there  is  a  clear  understanding  of  how  the  code 
will  be  used.  The  nature  of  the  application/s  of  the  code 
will  govern  the  information  a  coding  system  should  capture. 

OIR's  first  activity  in  a  code  development  project  is  to 
identify  the  potential  applications  which  will  use  the  coding 
system.  It  is  essential  to  realistically  identify  as  many 
possible  applications  which  will  eventually  use  the  coding 
system  even  though  some  of  these  applications  will  take  place 
in  the  future. 

A  classification  and  coding  system  should  not  be  developed  in 
isolation.  OIR  has  reviewed  many  coding  systems  developed  at 
various  companies  and  found  mostly  simple  codes  for  isolated 
applications.  The  isolated  application  approach  to  code 
development  leads  to  a  system  which  quickly  becomes  too 
limited  and  often  has  to  be  replaced. 

Often,  a  company  will  abandon  the  code  and  not  expend 
additional  man-hours  developing  a  new  replacement  code.  These 
experiences  have  created  some  skepticism  regarding  the 
usefulness  of  coding  systems. 

OIR  is  strongly  committed  to  the  philosophy  of  creating  an 
integrated  applications  database  which  is  accessed  by  the 
code  number.  Therefore,  it  is  essential  to  develop  a 
classification  and  coding  system  which  captures  the  necessary 
information  for  multiple  applications.  Development  of  a 
coding  system  for  one  application  should  not  create  obstacles 
for  the  use  of  that  code  in  other  applications.  The  format 
and  layout  of  the  code  will  also  be  influenced  by  the 
potential  applications.  The  code  structure  should  be  able  to 
adapt  to  changes  in  technology  -  a  most  important 
consideration  for  the  electronics  industry. 
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Therefore,  OIR  in  the  survey  and  interview  phase  of  this 
project  thoroughly  investigated  the  potential  applications  of 
an  ECACS  with  professionals  in  the  electronics  industry.  The 
following  potential  applications  were  identified: 

3.1.1  Design  Applications 

•  Design  Retrieval  -  ability  to  quickly  retrieve 

preferred  reference  design  for  review  and  possible 

re-use.  This  would  enable  a  company  to  make  optimal 

use  of  CAD  systems  and  improve  designer  productivity. 

•  Design  Documentation  Support 

-  creation  of  a  preferred  components  file/listing 
(including  specifications)  which  could  be  accessed 
by  using  the  code  number  for  immediate  data 
retrieval.  Additionally,  an  alternate  components 
program  could  be  used  when  a  designer  would  need  to 
identify  an  equivalent  component  when  the  preferred 
one  was  unavailable.  This  application  would 
provide  immediate  data  retrieval  and  eliminate 
time-consuming  clerical  search  activities  for  the 
designer. 

-  development  of  an  automated  program  for  creating 
design  specifications,  storing  previously  used 
specifications  and  retrieval  of  design 
specifications.  (Design  specifications  could 
include  function  specs  for  an  assembly,  component 
specs ,etc . ) 

3.1.2  Manufacturing  Applications 

•  Automated  production  specification  generation. 

-  This  would  include  process  documentation  and  test 
specification.  Inherent  in  the  program  would  be 
the  ability  to  create,  store  and  retrieve  data 
necessary  to  support  these  documentation 
activities.  Once  again  past  proven  experience  in 
the  form  of  preferred  reference  production  specs 
could  be  quickly  retrieved  for  re-use  either  as  is 
or  in  an  edited  version,  thereby,  improving 
manufacturing  engineering  productivity. 

•  Automated  Components  Inventory  Listing. 

•  Automated  Component  Status  Specification. 

-  This  would  identify  parts  obsolescence  and  parts 
performance  data;  also  vendor  performance.  The 
code  number  would  provide  quick  determination  of 
alternates.  Obsolescence  planning  and  second 
sourcing  would  be  enhanced  in  this  application. 


After  applications  have  been  identified,  OIR  reviews  these 
applications  to  determine  which  one  offers  the  greatest 
potential  return  on  investment.  The  inital  code  development 
will  specifically  address  that  application  but  the  final  code 
will  be  structured  so  as  to  accommodate  future  applications. 

An  additional  factor  identified  which  must  be  considered  when 
developing  a  Group  Technology  code  for  electronics  is  the 
particular  area  of  electronics  manufacture  (electronics 
family)  where  the  code  will  be  used.  The  survey  and 
interview  data  indicating  the  following  families  would  be 
best  suited  for  the  application  of  an  ECACS  in  both  design 
and  manufacturing: 

•  PCB , 

•  PCBA, 

•  Elec/Mechanical, 

•  Wired/Assembly, 

•  Discretes  (all  types  of  individual  components). 

3.1.3  Implications  for  an  ECACS 

After  reviewing  the  data  regarding  potential 
applications,  an  ECACS  should: 

•  capture  both  design  and  manufacturing  information 
so  as  to  be  useful  to  multiple  users.  Design 
information  can  be  captured  by  approximately  4-6 
characteristics.  Manufacturing  information  can  be 
captured  by  approximately  10-25  characteristics 
because  of  the  greater  detail  necessary  for 
manufacturing  applications. 

•  facilitate  the  integration  of  CAD/CAM  systems  and 
the  integration  of  databases  by  becoming  the 
common  means  of  accessing  these  systems. 

•  be  structured  with  enough  flexibility  to  keep  pace 
with  changing  technology. 

•  be  a  comprehensive  structure  so  as  to  cover  all 
areas  of  electronics  manufacture  (all  the 
families) . 


3 .2  Existing  Software  Utility  Programs 

A  classification  and  coding  system  only  becomes  effective 
when  coupled  with  good  software  utility  programs.  Utility 
programs  together  with  required  data  files  will  build  the 
integrated  applications  database.  Developing  a 
classification  and  coding  system  which  can  use  well  chosen, 
proven  software  utility  programs  can  eliminate  the  costly  and 
time  consuming  development  effort  required  to  create  software 
programs  in-house. 


Therefore,  after  potential  applications  have  been  identified, 
OIR's  next  task  in  code  development  is  to  review  all  relevant 
existing  software  utility  programs.  Once  a  decision  is  made 
regarding  existing  programs,  the  code  must  be  structured  so 
its  format  and  layout  are  compatible  with  the  existing 
software  programs.  Additionally,  this  focuses  the  code 
development  team  on  the  concept  of  creating  an  integrated 
applications  database  and  the  means  of  accessing  it. 

Some  examples  of  software  utility  programs  which  would  be 
considered  follow.  This  is  not  an  inclusive  listing. 

•  Standardized  Retrieval  Program 

A  standardized  retrieval  module  which  allows  for 
fast,  first  line  retrieval.  This  is  a  necessity 
given  that  if  you  have  a  code  number  and  unlimited 
time  you  can  find  anything.  However,  the  advantage 
of  a  code  number  coupled  with  a  good  retrieval  system 
is  immediate  access  to  desired  data. 

•  Software  Communication  Program 

A  program  designed  to  be  the  link  between  data 
retrieval  and  data  handling.  This  is  the  software 
that  allows  you  to  use  the  "do"  systems  more 
effectively  (i.e.  MIGRAPHICS  facilitates  the 
activities  of  a  CADD  system). 

•  Data  Handling  Programs 

A  standard  "do"  modules  which  handles  retrieved  data 
for  a  specific  application  (computer  aided  process 
planning).  The  code  number  could  directly  access 
such  a  program  (i.e.  MIPLAN  Process  Planning 
Systems ) . 

•  Analysis  Programs 

A  standard  program  which  will  perform  a  statistical 
analysis  of  data  for  a  particular  application  (i.e. 
The  MIGROUP  System  does  statistical  analysis  for 
Group  Technology  applications). 


3.2.1  Implications  for  an  ECACS 

Before  the  development  of  an  electronics  classification 
and  coding  system  begins,  a  thorough  review  of 
appropriate  existing  software  programs  should  be 
completed.  During  the  on-site  interview  process  OIR 
did  not  discover  any  standardized  utility  programs  in 
use  at  the  ten  electronics  manufacturers  visited. 
However,  OIR  is  aware  that  a  more  intensive  review  is 
necessary . 
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3 . 3  ECACS  Code  Format  and  Layout 

Even  though  survey  data  did  not  identify  existing  software 
programs  compatible  with  a  Group  Technology  Electronics 
Classification  and  Coding  System,  OIR  has  used  its  own 
MIGROUP  System  -  Group  Technology  Analysis  Programs  -  in  all 
of  its  code  development  projects.  The  MIGROUP  Software 
enables  OIR  to  significantly  reduce  the  time  and  manpower 
requirements  necessary  to  perform  the  activities  of  code 
development.  Therefore,  OIR  recommends  the  use  of  MIGROUP  or 
an  equivalent  system  to  do  the  analysis  necessary  for  the 
development  of  an  ECACS. 

3.3.1  Implications  for  an  ECACS 

The  Group  Technology  Classification  and  Coding  System 
for  Electronics  should  be  a  numeric  code  with  a  maximum 
of  thirty  digits  so  that  it  will  be  compatible  with 
existing  Group  Technology  analysis  program  software. 

If  this  structure  is  used  it  will  greatly  facilitate 
the  code  development  process. 
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Section  4 

GROUP  TECHNOLOGY  CODE  DEVELOPMENT 


After  potential  applications  and  support  software  programs  have 
been  identified,  actual  code  development  activities  begin. 


4 . 1  Code  Development  Start-up  Activities 

During  a  typical  code  development  project,  OIR  performs  the 
following  activities  during  project  start-up. 

•  Review  potential  applications,  support  software  and  any 
other  requirements  for  the  code. 

•  Determine  the  particular  characteristics  and  information 
the  code  should  capture. 

•  Determine  level  of  detail  (for  information)  to  be 
captured  by  the  code. 

The  level  of  detail  depends  on: 

-  total  number  of  items  to  be  coded  (100  items  require 
less  detail  than  100,000  items). 

-  type  of  application: 

design  retrieval  requires  less  detail  in  the  code 
than  shop  floor  analysis  or  process  plan  retrieval. 

-  type  of  coding  system: 

coding  system  for  50  parts  in  each  sub-assembly 
requires  more  than  a  coding  system  for  50 
sub-assembi ies  in  a  few  final  assemblies. 


4.2  Code  Structure  Development 


Upon  completion  of  these  start-up  activities,  OIR  begins  to 
develop  the  actual  code.  OIR  splits  the  code  structure  into 
two  sections: 

•  A  standard  section  which  carries  the  general  information 
which  applies  to  every  item  to  be  coded; 

•  and  a  specific  section  which  carries  the  information 
which  is  specific  to  only  one  item  grouping.  In  the  case 
of  an  ECACS,  the  specific  section  of  the  code  would 
capture  information  pertaining  to  one  electronics  family 
grouping  (i.e.  IC's,  Hybrids,  etc.)  only.  Each 
electronics  family  will  have  a  separate  specific  section 
of  the  code. 
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The  following  illustration  depicts  OIR's  method  of  code 
development . 


STANDARD  SECTION 


SPECIFIC  SECTION 


1  234S678  xxxxxxxxxxxxxxxx  25  26  27  28  29  30 


*-  >  >  > 

Start 
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The  code  is  developed  by  beginning  with  a  limited  number  of 
digits  for  the  standard  section.  The  standard  section  of  the 
code  will  perform  an  initial  split  of  the  data  in  order  to 
define  broad  family  groups.  The  standard  section  of  an  ECACS 
will  begin  to  define  the  electronics  family  groups  (i.e.  PWB, 
wired/assy,  etc.)  in  this  initial  split  of  the  data.  A 
relatively  small  standard  code  section  will  be  developed  (4-6 
digits  only). 

OIR  then  begins  to  develop  a  specific  section  of  the  code  for 
each  of  the  groups  defined  in  the  initial  split  of  the  data. 
The  specific  section  of  the  code  in  an  ECACS  will  capture 
information  relevant  to  a  particular  family  grouping.  For 
example,  the  Integrated  Circuit  family  specific  code  section 
will  capture  lead  configuration,  type  of  packaging,  type  by 
funtion,  circuit  performance,  etc.  Again,  it  is  recommended 
at  this  level  of  development  to  keep  each  specific  section  of 
the  code  simple  (4  digits). 

Development  of  the  standard  and  specific  sections  of  the  code 
begins  at  the  end  digits  (OIR's  standard  code  structure  is  30 
digits)  and  develops  towards  the  center.  The  x's  in  the 
diagram  represents  spaces  held  for  undefined  digits. 

The  coding  system  that  is  developed  during  this  phase  of  the 
project  should  allow  for  the  eventual  expansion  of  the 
standard  and  specific  sections  of  the  code.  OIR's  methodology 
facilitates  that  expansion  requirement. 


4.2.1  Implications  for  ECACS 
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OIR  recommends  that  the  above  methodology  be  used  to 
develop  the  ECACS  as  it  insures  the  flexibility 
necessary  for  code  expansion,  during  development  as  well 
as  actual  application. 

The  first  cut  at  developing  an  ECACS  should  yield: 

•  a  maximum  of  eight  digits  for  the  standard  section 
of  the  code; 

•  and  a  maximum  of  4  digits  for  each  specific  section 
of  the  code. 

Note:  Digit  development  includes  the  definition  of 

all  appropriate  values  for  these  digits. 


4 . 3  Group  Technology  Analysis  of  Code  Structure 

The  next  step  in  code  development  is  to  use  this  initial 
coding  system  to  code  a  random  sample  of  items  (1000)  within 
the  chosen  area  of  application  thus  creating  a  database  for 
the  coded  items  (ECACS  -  code  1000  components).  OIR  then  uses 
the  MIGROUP  Group  Technology  Analysis  programs  to  determine 
the  effectiveness  and  completeness  of  the  code  structure. 

At  the  same  time  an  analysis  database  is  built  that  contains 
"raw  data".  This  analysis  database  serves  two  purposes: 

•  Researches  the  effectiveness  of  the  ECACS  for 
retrieval  of  meaningful  clusters  of  raw  data.  This 
simulates  the  effectiveness  of  the  code  as  "glue" 
for  applications  databases. 

•  Researches  whether  the  correct  balance  has  been 
established  between  compressed  data  (or  ECACS)  and 
raw  data.  The  ECACS  should  only  contain  the  minimum 
amount  of  meaningful  characteristics  that  enables 
the  user  to  access  a  border  set  of  "raw"  data. 

The  MIGROUP  System  (or  equivalent  Group  Technology  analysis 
program)  is  used  to: 

•  perform  a  specific  analysis  of  the  code  for 
redundancy  of  information  captured  by  the  digits. 
Often  in  the  initial  structuring  of  a  coding  system, 
the  same  information  is  captured  by  various  digits. 
This  analysis  identifies  those  cases.  The  code  is 
more  clearly  defined  so  that  redundancy  is 
eliminated  by  further  compression  of  the  code 
structure.  After  all,  a  code  structure  is  a 
compressed  version  of  much  greater  amounts  of  raw 
dat  a. 
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•  perform  an  analysis  to  determine  code  utilization. 
This  analysis  checks  the  combination  of  key 
characteristics  to  determine  if  looking  at  these 
groupings  will  yield  the  specific  information  needed 
for  a  specific  application.  The  characteristics 
captured  by  the  initial  code  structure  can  be  very 
general  in  nature  and  if  examinedsingly  will  not 
yield  information  to  point  to  a  specific  item. 
However,  when  key  characteristics  are  grouped  they 
should  identify  specific  items.  Eventually 

simil iarities  in  design  and  function  will  be 
identified  by  grouping  digits.  This  analysis 
reviews  the  code  to  insure  that  it  can  be  used  to 
satisfy  application  requirements. 

•  perform  an  analysis  of  the  code  structure  to 
determine  if  and  how  the  code  needs  expansion.  This 
analysis  will  reveal  if  the  code  needs  more  detail 
in  order  to  split  the  data  into  coherent  and 
cohesive  groups.  This  analysis  will  direct  the 
further  resolution  of  the  code  structure  by 
identifying  details  about  the  characteristics 
necessary  to  describe  these  data  groups. 

The  development  of  a  coding  system  is  an  iterative 
process.  The  basic  methodology  set  forth  above  is 
repeated  until  the  code  structure  performs  according 
to  the  requirements  necessary  for  the  application. 


4.3.1  Implications  for  ECACS 

In  order  to  develop  a  Group  Technology  Electronics 
Classification  and  Coding  System  with  industry-wide 
appeal  and  application,  OIR  recommends  the  following: 

•  The  code  structure  should  be  comprehensive  enough  to 
cover  all  areas  of  electronics  manufacture  (all 
electronics  family  grouping  -  see  Section  51. 

The  code  should  be  structured  to  capture  information 
useful  in  design,  manufacture  and  test. 

•  The  code  should  be  capable  of  expansion  and/or 
change  to  reflect  the  changing  technology  within 
electronics. 

•  The  code  should  be  developed  so  as  to  be  compatible 
with  existing  software  programs  to  the  degree 
possible.  The  ECACS  can  become  a  strong  force  in 
the  integration  of  isolated  CAD  and  CAM  Systems. 
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•  The  MIGROUP  Group  Technology  Analysis  Programs  or 
equivalent  should  be  used  to  structure  and  develop 
the  code.  This  will  ensure  the  development  of  a 
code  which  can  work  with  existing  group  technology 
applications  software. 

•  The  code  should  be  as  simple  and  compressed  as 
possible  to  facilitate  use.  Coding  should  be  done 
interactively  using  the  terminal.  Training  and  use 
of  the  code  should  be  user  friendly. 


Section  5 


ECACS:  STANDARD  SECTION  OF  CODE 


Based  upon  survey  and  interview  data,  the  following  information 
should  be  captured  in  the  Standard  Section  of  an  Electronics 
Classification  and  Coding  System. 


5 . 1  Family  Categories 

The  following  family  categories  were  identified  as  primary, 
discrete  areas  (functional  grouping)  within  electronics 
manufacturing. 

•  Packaging  (panels,  covers,  chassis,  etc.) 

•  Wired  Assemblies  (cables,  harnesses,  point  to  point) 

•  Printed  Wiring  Boards 

•  Discrete  Components 

•  Integrated  Circuits 

•  Hybrid  Microelectronics 

•  Wire  Wound  Magnetic  Components 

•  Electronic  Assemblies 

•  Electro-Magnetic  Assemblies 

•  Electro-Optics 

•  Hardware 

Definitions  for  these  families  can  be  found  in  the  Glossary 
(Appendix  A). 


5 . 2  General  Characteristics 

An  ECACS  should  capture  the  following  general  characteristics 
in  the  Standard  Section  of  the  code.  These  characteristics 
apply  to  all  components  to  be  coded.  This  information  is 
necessary  for  design,  manufacture  and  test  engineering  and  has 
been  identified  as  of  primary  importance  by  all  respondents. 
The  characteristics  are  listed  in  order  of  importance. 

1.  Function 

2.  Dimensional  Parameters 

3.  Electronic  Parameter s/Spec ifications 

4.  Tolerances 

5.  Test  Criteria 

6.  Annual  Quantity 

5.2.1  Function 

This  is  the  most  important  characteristic  to  be  captured 
in  the  code.  Functional  description  of  the  component 
will  quickly  split  the  database  into  manageable  sections 
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for  quick  search  and  retrieval  routines.  This 
description  will  reflect  the  family  groups  delineated 
above.  01R  estimates  it  will  take  1-2  digits  for  the 
functional  description. 

Additionally  components  to  be  coded  will  need  functional 
descriptions  particular  to  family  grouping.  These 
characteristics  will  be  captured  in  the  specific  section 
of  the  code. 

5.2.2  The  Remaining  Characteristics 

-  Dimensional  Parameters  (dimensions) 

-  Electronic  Parameters/Specifications 
(wattage,  voltage,  impedence) 

-  Tolerances 

-  Test  Criteria 

-  Annual  Quantity 

are  self  explanatory  and  were  universally  identified  by 
electronics  manufacturers  as  crucial  information. 

These  characteristics  are  necessary  for  design, 
manufacturing  applications  (i.e.  automated  insertion  vs 
manual)  and  testing. 

5 . 3  Additional  Concerns 

As  a  result  of  OIR's  on-site  interviews  with  electronics 
professionals  some  additional  topics  of  concern  were 
identified.  These  concerns  were  raised  at  each  company 
visited  and  should  be  explored  fully  during  the  development  of 
an  ECACS. 

5.3.1  Obsolescence 

The  electronics  industry  is  driven  by  a  constantly 
changing  technology.  The  nature  of  technological 
advances  often  is  reflected  in  component,  sub-assembly 
and  process  obsolescence.  Most  electronics  engineers 
were  concerned  with  capturing  data  about  obsolescence 
and  being  able  to  quickly  retrieve  this  data. 

Additionally,  obsolescence  presents  real  concerns  for 
components  inventory  control,  product  reliability  and 
maintenance  and  carrying  costs  of  inventory  and  finished 
goods . 

At  this  time,  01R  believes  the  area  of  obsolescence 
needs  further  exploration  in  order  to  decide  the  best 
way  to  handle  the  problem.  Two  solutions  are  readily 
apparent : 


•  develop  a  code  structure  which  would  capture  this 
characteristic  in  the  standard  section  of  code. 

•  develop  a  separate  data  file  for  obsolescence  which 
could  be  accessed  by  the  code  number. 

Obsolescence  data  would  be  a  separate  file. 

The  question  of  obsolescence  must  be  investigated  in 
greater  detail  prior  to  making  such  a  decision. 

5.3.2  Reliability 

During  the  interview  sessions,  a  substantial  number  of 
electronics  professionals  identified  a  need  to  code 
reliability  data.  Component  reliability  affects  end 
product  quality  and  performance  and  substantially 
impacts  the  rigor  of  the  testing  procedures  a  company 
establishes  as  standards. 

Electronics  industry  personnel  would  like  to  capture  the 
following  reliability  data: 

•  history  of  component  performance 

•  testing  standards 

•  vendor  reliability 

Reliability  data  may  be  captured  in  some  other  digits  in 
the  electronics  code  structure  through  review  of 
performance  parameters,  tolerances  and  testing 
procedures.  This  is  a  good  example  of  the  need  to 
perform  a  Group  Technology  analysis  of  the  code 
structure  during  development.  The  analysis  will  provide 
information  on  whether  reliability  information  is 
captured,  where  it  is  captured  and  if  the  code  needs 
more  detail  for  this  characteristic. 


5 .4  Recommendat ions 

In  order  to  develop  the  standard  section  fo  an  ECACS,  OIR 
recommends: 

•  capturing  information  about  six  general 
characteristics: 

Function, 

Dimensional  Parameter, 

Electronics  Parameters/Specifications , 
Tolerances , 

Test  Criteria, 

Annual  Quantity. 

•  creating  a  code  structure  of  a  maximum  of  eight 
digits  to  describe  these  characteristics. 


•  performing  a  Group  Technology  analysis  of  the  code 
structure  during  development  using  the  MIGROUP 
System  or  equivalent. 

•  further  investigations  into  applications,  existing 
software  programs  and  issues  of  reliability  and 
obsolescence . 
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Section  6 

ECACS:  SPECIFIC  SECTION  OF  THE  CODE 

The  specific  section  of  an  ECACS  will  be  developed  for  each  of  the 
main  functional  categories  defined  in  the  standard  section  of  the 
code.  Characteristics  will  be  captured  which  are  category 
spec i f ic . 

The  following  sections  of  this  report  outline  the  information  to 
be  captured  by  an  ECACS  for  each  main  functional  category.  This 
outline  was  developed  as  a  result  of  the  survey/interview  data 
analysis  and  review  by  the  project  team. 

The  primary  and  secondary  characteristics  must  be  captured  for 
both  design  and  manufacturing  applications. 

The  delineation  of  types  of  testing  required  are  of  primary 
interest  for  manufacturing  applications. 
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6.1  Functional  Category:  Packaging 

•  Primary  Characteristics 

-  Shape 

-  Shape  Elements  (holes,  slots,  etc.) 

-  Material 

-  Surface  Treatments 

•  Secondary  Characteristics 

-  Position  of  Shape  Elements 

-  Quantity  of  Shape  Elements 

-  Major  Machining  Operations 

-  Major  Fabrication  Operations 

•  Types  of  Testing 

-  Dimensional  Analysis 

-  Metallurgical/Material  Evaluation 

-  Stress/Strength  Analysis 

-  Color,  Texture  (Aesthetic  Evaluation) 

-  Static  Dissipation 

-  EMI  Shielding 
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6.2  Functional  Category:  Wired  Assemblies 


•  Primary  Characteristics 

-  Number  of  Conductors 

-  Size  of  Conductors 

-  Type  of  End  Terminations 

-  Type  of  Insulation 

-  Number  of  Branches 

-  Type  (e.g.  flat,  ribbon,  coax) 

•  Secondary  Characteristics 

-  Type  of  Base  Material 

-  Type  of  Surface  Plating 

-  Shielding 

-  End  Product  Destination 

-  Machine  Operations 

-  Manual  Operations 

-  Coating/Encapsulation 

-  Joining  Processes 

•  Types  of  Testing 

-  Dimensional 

-  Opens/Shorts  Testing 

-  Impedence  Testing 

-  Hi-Pot  Testing 


6.3  Functional  Category:  Printed  Wiring  Boards  (PWB) 

•  Primary  Characteristics 

-  Type  of  Base  Material 

-  Type  of  Conductive  Material 

-  Number  of  Layers 

-  Types  of  Layers 


•  Secondary  Characteristics 

-  Shape 

-  Conductor  Electrical  Characteristics 

-  Environment  Requirements 

-  Printed  Circuitry  Processes 

-  Hole  Information  (size,  quantity,  etc.) 

-  Plating  Information 

-  Masking  and  Coating 

•  Types  of  Testing 

-  Bond  Evaluation  (layer) 

-  Bond  Evaluation  (conductor) 

-  Metallurgical  Evaluation  of  Plating  Quality 

-  Dimensional 

-  Electrical  Testing 

-  Micro  Sectioning 
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6.4  Functional  Category:  Discrete  Component 

•  Primary  Characteristics 

-  Type  of  Package 

-  Lead  Configuration 

-  Component  Type 

•  Secondary  Characteristics 

-  Environmental  Specifications 

-  Adjustability 

•  Types  of  Testing 

-  Parametric 

-  Functional 

-  Dimensional 

-  Environmental 


6.5  Functional  Category:  Integrated  Circuits 

•  Primary  Characteristics 

-  Type  of  Packaging 

-  Lead  Arrangements 

-  Type  by  Function 

•  Secondary  Characteristics 

-  Scale  of  Integration  (LSI, SSI,  etc.) 

-  Circuit  Performance 

-  Number  of  Leads 

-  Environmental  Requirements 

•  Types  of  Testing 

-  Parametric  Testing 

-  Functional  Testing 

-  Pattern  Sensitivity  Testing 

-  Burn-In 

-  Dynamic 


6.6  Functional  Category:  Hybrid  Micro  Electronics 

•  Primary  Characteristics 

-  Type  of  Packaging 

-  Lead  Arrangement 

•  Secondary  Characteristics 

-  Number  of  Leads 

-  Internal  Circuit  Types 

-  Number  of  Internal  Elements 

-  Lead  Related  Dimensions 

-  Environmental  Specifications 

•  Types  of  Testing 

-  Physical  Characteristics 

-  Parametrics 

-  Functional  Testing 

-  Static  Testing 


6.7  Functional  Category:  Wire  Wound  Magnetic  Components 

•  Primary  Characteristics 

-  Shape 

-  Function 

-  Winding  Wire  Data 

-  Lamination  Data 

-  Type  of  Shielding/Sleeving 

•  Secondary  Characteristics 

-  Adjustability 

-  External  Lead  Data 

-  Machine  Processes 

-  Major  Fabrications  Operations 

-  Coating/Encapsulation 

•  Types  of  Testing 

-  Induction 

-  Impedence 

-  Coupling 

-  Load  Effects 

-  Excitation  Current 

-  Permeability 

-  Voltage/Current/Frequency  Data 

-  Hi-Pot 

-  Dimensions 

-  Resistance 


& 


6.8  Functional  Category:  Electronic  Assemblies  (EA) 


•  Primary  Characteristics 

-  Shape 

-  Function 

-  Type  of  Composite  Components 

-  Major  Fabrication  Operations 

•  Secondary  Characteristics 

-  Component  Spacing  Information 

-  Special  Packaging 

-  Environmental  Requirements 

-  Coat/Encapsulation 

•  Types  of  Testing 

-  Functional  Testing 

-  In  Circuit  Testing 

-  Parametrics 

-  Dynamic  Testing 

-  In-Product  Substitution 

-  Environmental  Chamber 


6.9  Functional  Category:  Electro-Mechanical  Assemblies 

•  Primary  Characteristics 

-  Shape 

-  Function/s 

-  Type  of  Electronic  Components 

-  Quantity  of  Electronic  Components 

-  Major  Assembly  Operations 

•  Secondary  Characteristics 

-  Type  of  Mechanical  Components 

-  Quantity  of  Mechanical  Components 

-  Type  of  Electro-Optical  Components 

-  Quantity  of  Electro-Optical  Components 

-  Major  Machining  Operations 

-  Coating/Encapsulation 

-  Joining  Processes 

•  Types  of  Testing 

-  Functional  Testing 

-  Parametrics 
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6.10  Functional  Category:  Electro-Opt ics 


•  Primary  Characteristics 

-  Type  of  Packaging 

-  Lead  Configuration 

-  Coupling  Techniques 

-  Performance/Optical  Parameter 

•  Secondary  Characteristics 

-  All  characteristics  offered  for  review  were 
considered  of  primary  importance  in  Electro- 
Optics. 

•  Types  of  Testing 

-  Dimensional 

-  Signal  Transmission 

-  Parametrics 


6.11  Functional  Category:  Hardware 

•  Primary  Characteristics 

-  Type  of  Hardware 

-  Shape 

-  Base  Material 

-  Surface  Treatment 

-  Custom  or  Standard 


•  Secondary  Characteristics 

-  Mounting  Technique 

-  Machining  Operations 

-  Fabrication  Operations 


•  Types  of  Testing 

-  Dimensional 

-  Metalurgical/Mater ial 

-  Aesthetics 

-  Plating  Analysis 


APPENDIX  A 


GLOSSARY 


1.  PACKAGING  Packaging  encompasses  the  elements 

(components/asserabi ies)  which  are 
required  to  create  a  "black  box"  which 
will  contain  electronic  components, 

(i.e.  panels,  covers,  chassis,  etc.). 

2.  WIRED  ASSEMBLIES  An  assembly  consisting  of  multiconductor 

grouping  of  wires,  point  to  point 
wiring,  etched/additive  wire  assemblies, 
and/or  flexible  printed  cables. 

3.  PRINTED  WIRING  A  completely  processed  conductor 

BOARDS  (PWB)  pattern(s)  all  formed  on  a  common  base. 

4.  DISCRETE  COMPONENT  Any  passive  or  active  electronic 

component,  other  than  integrated 
circuits  and  hybrid  microelectronics, 
(e.g.  capacitors,  resistors,  switches, 
diodes,  transistors,  etc.). 

5.  INTEGRATED  CIRCUITS  A  complex  electronic  semiconductor 

circuit,  packaged  as  an  individual 
component . 

6.  HYBRID  MICRO  A  packaging  technique  that  interconnects 

ELECTRONICS  passive  and/or  semiconductor  devices 

within  a  single  package. 

7.  WIRE  WOUND  MAGNETIC  Any  device  which  acts  or  reacts  due  to 

COMPONENTS  the  electromagnetic  field  induced  by 

current  flowing  through  wire  windings. 
This  shall  include  transformers, 
actuators,  rotary  components  and  coils. 

A  final  assembly  or  second  level 
assembly  which  includes  a  printed 
circuit  board.  These  shall  contain 
electronic,  mechanical,  and/or  optical 
component  s . 


8.  ELECTRONIC 

ASSEMBLIES  (EA) 


9.  ELECTRO-MECHANICAL  A  final  or  secondary  level  assembly 
ASSEMBLIES  which  performs  an  electronic  function, 

but  is  manufactured  using  basically 
mechanical  operations  such  as  staking, 
riviting,  screws,  bolting  and  hard 
mounting  of  electronic  or  optical 
components . 

10.  ELECTRO-OPTICS  Electronic  device  or  assembly  which 

integrates  electrical  and  optical  signal 
carrying  medium. 

11.  HARDWARE  Various  electro-mechanical  and 

mechanical  components  utilized  in  the 
different  categories  of  assemblies  (e.g. 
knobs,  dials,  connectors,  etc.). 


